Field
This disclosure is generally related to name resolutions in networks. More specifically, this disclosure is related to a method and a system that can provide a unifying framework for name resolution across heterogeneous name-resolution systems.
Related Art
Service discovery and name resolution are vital operations in any network. Users and applications often use text-based strings, such as uniform resource locators (URLs), rather than network addresses to indicate the content or services they require, and these names must then be mapped to network addresses before communication is possible. Such a name-resolution requirement applies to today's and future networks and the Internet at large.
Unfortunately, current approaches to name resolution are unable to support future networking environments that include different types of network, each using a different name-resolution protocol. This is because no single name-resolution protocol has been devised that works well across all types of network, and the different currently available name-resolution protocols have not been designed to interoperate with one another. For example, consider the case in which a user accidentally leaves her laptop at home and wishes to access it from her office. The laptop most likely uses multicast domain name system (mDNS) to name itself on the home network, but the user has no way of resolving this name outside of that home network environment and, thus, cannot discover the laptop. As another example, nodes in a mobile ad hoc network (MANET) may use a distributed protocol to resolve each other's names, but there is no protocol for them to extend this name resolution to the Internet through the domain name system (DNS), despite the presence of a network-layer gateway bridging the MANET to the Internet.
Currently available systems for name resolution and service discovery can be loosely categorized into client-server systems, peer-to-peer systems, or systems based on overlay networks. Additionally, there are hybrid systems employing more than one of these architectures.
The most widely used system for name resolution today is the domain name system (DNS). DNS relies on a hierarchy of servers that must be configured to forward a name request to the appropriate server, which then resolves that name request to an IP address. Through the use of this hierarchy, load-balancing “secondary” servers, and caching, DNS provides name resolution for the entire Internet today. However, this scalability comes with a price. First, DNS relies completely on these servers: if the authoritative DNS server for a subdomain “example.com” is down, overloaded, or configured incorrectly, then all DNS lookups for “*.example.com” will fail and “www.example.com” is not reachable, regardless of the state of the web server itself. Second, the DNS relies on hosts to configure their IP addresses with their DNS servers using out-of-bound communications, which results in a static system that cannot support dynamic networks. Dynamic DNS seeks to alleviate these limitations by specifying an UPDATE record type; however, it still requires that (1) the host knows the IP address of its authoritative DNS server a priori, and (2) the host successfully sends an update to the authoritative server every single time its IP address changes.
Examples of peer-to-peer systems include mDNS, Simple Service Discovery Protocol (SSDP), and Service Location Protocol (SLP). These peer-to-peer systems do not require a central server to operate, and as a result, minimal configuration is required. These zero configuration (zeroconf) systems are well suited for dynamic environments where hosts come up, go down, and change IP addresses frequently, such as home networks configured with Dynamic Host Configuration Protocol (DHCP) or AutoIP. Unfortunately, all peer-to-peer systems currently share a heavy reliance on IP multicast to propagate both name requests and service announcements through the entire network. As a result, they suffer from relatively high latency and cannot scale, which restricts these protocols to local area networks (LANs) where internal names are denoted by the top-level domain (TLD), “.local.”
It is also possible to deploy DNS over an overlay network that uses a distributed hash table (DHT) to reduce the load on individual servers and thus provide higher scalability and better fault tolerance. DHTs serve to decouple the physical location of an entry from its logical location. This architecture helps with load-balancing, removes hot spots and bottlenecks in the hierarchy, and creates a system that is orders of magnitude harder to attack. These benefits are typically achieved by enforcing a flat namespace, where all records in the system are stored as equal objects in one giant DHT. Unfortunately, these approaches rely on a network environment in which the nodes of the overlay are static and available with high uptime, the topology is connected, and links have plenty of bandwidth. The performance of DHTs degrades significantly in dynamic networks as a result of excessive overhead resulting from topology-independent overlay addresses, link failures, and node mobility.
SLP introduces the concept of an optional “Directory Agent” (DA). In the SLP system, all nodes in a network must contact the DA first if it is present. In the case of MANETs, a virtual backbone of “Service Broker Nodes” (SBNs) forms a dominating set in a MANET and proactively maintains routes through the MANET to each other. These approaches attempt to increase scalability by only allowing a select subset of nodes to query the entire network, and requiring that other nodes communicate with their closest directory node. However, they all share the same drawback. More specifically, in these systems communication between directory nodes is unstructured and accomplished by flooding a name request to all other directory nodes, which scales as poorly as the peer-to-peer systems. Multi-level distributed hash table (MDHT) addresses this issue by proposing a hierarchy of DHTs, but cannot scale to large numbers of records because it requires the top-level DHT to contain every record in the system.
Currently available name-resolution protocols lack interoperability, meaning that the different protocols (such as mDNS and DNS) cannot talk to each other, even though mDNS might be best for home networks and DNS might be best for the Internet. One way to support multiple protocols is to designate some top-level domains or TLDs (such as “.local”) for certain protocols and to have the node generating a request use the TLD to decide which protocol should be used. Other approaches have been limited to developing higher-layer application programming interfaces (APIs) that mask implementation differences between protocols that already share the same basic architecture, such as SSDP and SLP. Another approach for interoperability across different network architectures, both for routing and name resolution is to divide networks into contexts and use interstitial functions to translate between contexts, instead of requiring all networks to use the same protocol. However, the latter approach may still face problems of scalability and coherency if the number of separate contexts becomes too high or if entire contexts exhibit a high degree of mobility.